Prior to setting forth the background of the invention, it may be helpful to set forth definitions of certain terms that will be used hereinafter.
The term “Network-attached storage” or “NAS” as used herein is defined is a file-level computer data storage server connected to a computer network providing data access to a heterogeneous group of clients. NAS is specialized for serving files either by its hardware, software, or configuration. It is often manufactured as a computer appliance—a purpose-built specialized computer. NAS systems are networked appliances which contain one or more storage drives, often arranged into logical, redundant storage containers or RAID.
Network-attached storage removes the responsibility of file serving from other servers on the network. They typically provide access to files using network file sharing protocols such as NFS, SMB/CIFS, or AFP. NAS devices are a convenient method of sharing files among multiple computers. Potential benefits of dedicated network-attached storage, compared to general-purpose servers also serving files, include faster data access, easier administration, and simple configuration.
Some NAS devices are configured to serve end-clients using a variety of file-sharing-protocols such as, for example, SMB1/2/3, NFS3/4/4.1 and FTP, and variety of operating system (OS) types, such as, but not limited to, MS-Windows: Windows XP, Win7, Win8, win10, 2003, 2008, 2012, a variety of Linux OS flavors, UNIX and different Mac OS versions.
The different OSs may implement different sub-versions (“dialects”) of the corresponding protocol, and the different clients may make use of different working conventions and work flows while communication with the NAS file-server.
In order to test the compatibility of a file-server to a specification or request for comments (RFC) of a file-sharing protocol, it may be required to manipulate client-side features that are implemented by the OS and its underlying drivers. Operations that are being tested involve sending protocol commands on the OS level. The challenge of creating OS-level test scenarios on the packet level is shared by the entire NAS manufacturers' community.
In existing standard client test environments, the test application usually requests the operating system to communicate with the NAS. The operating system uses an internal driver to handle this communication, which uses the protocol's commands and command's field as it sees fit, including (for example) the use of client-side-cache. Therefore, it is a challenge to create and execute test scenarios that involve client-side features, such as scenarios that include commands that implement client-side cache and/or persistent file handles.
Exiting solutions are roughly divided into the following two types: load machines and code libraries.
Load machines such as, for example, the ones provided by Spirent and Load DynamiX, offer some capabilities to construct packet-level scenarios. However, the statistical form of their result reporting is a major drawback. It is impossible to get a deterministic result of the communication (passed or failed) without reviewing the generated packet analyzer (for example, Wireshark). Therefore it is highly irrelevant for regression testing.
Code libraries are tools offering coding implementation of packets, which require testing professionals with programming skills in order to construct relevant scenarios from the packets.
Microsoft test suites and SMB-torture are two different intermediate solutions between the load machines and the code libraries. The Microsoft test suites test a verity of SMB implementations. However, they do not allow modification of the scenarios themselves by the end-user. SMB torture (developed by Samba-team) enables adding new scenarios by using programming abilities.